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Abstract 


This document describes an extension to the Session Initiation 
Protocol (SIP) for publishing event state used within the SIP Events 
framework. The first application of this extension is for the 
publication of presence information. 


The mechanism described in this document can be extended to support 
publication of any event state for which there exists an appropriate 
event package. It is not intended to be a general-purpose mechanism 
for transport of arbitrary data, as there are better-suited 
mechanisms for this purpose. 
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1. Introduction 
This specification provides a framework for the publication of event 
state from a user agent to an entity that is responsible for 


compositing this event state and distributing it to interested 
parties through the SIP Events [1] framework. 
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In addition to defining an event publication framework, this 
specification defines a concrete usage of that framework for the 
publication of presence state [2] by a presence user agent [3] to a 
presence compositor, which has a tightly coupled relationship with 
the presence agent [1]. 


The requirements and model for presence publication are documented in 
[10]. This specification will address each of those requirements. 


The mechanism described in this document can be extended to support 
publication of any event state for which there exists an appropriate 
event package as defined in [1]. For instance, an application of SIP 
events for message waiting indications [11] might choose to collect 
the statuses of voice-mail boxes across a set of user agents using 
the PUBLISH mechanism. The compositor in such an application would 
then be responsible for collecting and distributing this state to the 
subscribers of the event package. 


Each application that makes use of the PUBLISH mechanism in the 
publication of event state will need to adhere to the guidelines set 
in Section 10. The mechanism described in this document is not 
intended to be a general-purpose mechanism for transport of arbitrary 
data, as there are better-suited mechanisms for this purpose. 


2. Definitions and Document Conventions 


In addition to the definitions of REC 2778 [3], REC 3265 [1], and REC 
3261 [4], this document introduces some new concepts: 


Event State: State information for a resource, associated with an 
event package and an address-of-record. 


Event Publication Agent (EPA): The User Agent Client (UAC) that 
issues PUBLISH requests to publish event state. 


Event State Compositor (ESC): The User Agent Server (UAS) that 
processes PUBLISH requests, and is responsible for compositing 
event state into a complete, composite event state of a resource. 


Presence Compositor: A type of Event State Compositor that is 
responsible for compositing presence state for a presentity. 


Publication: The act of an EPA sending a PUBLISH request to an ESC to 
publish event state. 


Event Hard State: The steady-state or default event state of a 


resource, which the ESC may use in the absence of, or in addition 
to, soft state publications. 
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Event Soft State: Event state published by an EPA using the PUBLISH 
mechanism. A protocol element (i.e., an entity-tag) is used to 
identify a specific soft state entity at the ESC. Soft state has 
a defined lifetime and will expire after a negotiated amount of 
time. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 [5] 
and indicate requirement levels for compliant implementations. 


Indented passages such as this one are used in this document to 
provide additional information and clarifying text. They do not 
contain descriptions of normative protocol behavior. 


3. Overall Operation 


This document defines a new SIP method, PUBLISH, for publishing event 
state. PUBLISH is similar to REGISTER in that it allows a user to 
create, modify, and remove state in another entity which manages this 
state on behalf of the user. Addressing a PUBLISH request is 
identical to addressing a SUBSCRIBE request. The Request-URI of a 
PUBLISH request is populated with the address of the resource for 
which the user wishes to publish event state. The user may in turn 
have multiple User Agents or endpoints that publish event state. 

Each endpoint may publish its own unique state, out of which the 
event state compositor generates the composite event state of the 
resource. In addition to a particular resource, all published event 
state is associated with a specific event package. Through a 
subscription to that event package, the user is able to discover the 
composite event state of all of the active publications. 


A User Agent Client (UAC) that publishes event state is labeled an 

Event Publication Agent (EPA). For presence, this is the familiar 

Presence User Agent (PUA) role as defined in [2]. The entity that 

processes the PUBLISH request is known as an Event State Compositor 
(ESC). For presence, this is the familiar Presence Agent (PA) role 
as defined in [2]. 


PUBLISH requests create soft state in the ESC. This event soft state 
has a defined lifetime and will expire after a negotiated amount of 
time, requiring the publication to be refreshed by subsequent PUBLISH 
requests. There may also be event hard state provisioned for each 
resource for a particular event package. This event state represents 
the resource state that is present at all times, and does not expire. 
The ESC may use event hard state in the absence of, or in addition 
to, event soft state provided through the PUBLISH mechanism. Setting 
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this event hard state or configuring the ESC policy regarding the 
aggregation of different event state is out of the scope of this 
specification. 


The body of a PUBLISH request carries the published event state. In 
response to every successful PUBLISH request, the ESC assigns an 
identifier to the publication in the form of an entity-tag. This 
identifier is then used by the EPA in any subsequent PUBLISH request 
that modifies, refreshes or removes the event state of that 
publication. When event state expires or is explicitly removed, the 
entity-tag associated with it becomes invalid. A publication for an 
invalid entity-tag will naturally fail, and the EPA needs to start 
anew and resend its event state without referencing a previous 
entity-tag. 


4. Constructing PUBLISH Requests 


PUBLISH requests create, modify, and remove event state associated 
with an address-of-record. A suitably authorized third party may 
also perform publication on behalf of a particular address-of-record. 


Except as noted, the construction of the PUBLISH request and the 
behavior of clients sending a PUBLISH request are identical to the 
general UAC behavior described in Section 8.1 and Section 17.1 of RFC 
3261 [4]. 


If necessary, Clients may probe for the support of PUBLISH using the 
OPTIONS request defined in SIP [4]. The presence of "PUBLISH" in the 
"Allow" header field in a response to an OPTIONS request indicates 
support for the PUBLISH method. In addition, the "Allow-Events" 
header field indicates the supported event packages. 


Note that it is possible for the OPTIONS request to fork, and 
consequently return a response from a User Agent other than the 
ESC. In that case, support for the PUBLISH method may not be 
appropriately represented for that particular Request-URI. 


A PUBLISH request does not establish a dialog. A UAC MAY include a 
Route header field in a PUBLISH request based on a pre-existing route 
set as described in Section 8.1 of RFC 3261 [4]. The Record-Route 
header field has no meaning in PUBLISH requests or responses, and 
MUST be ignored if present. In particular, the UAC MUST NOT create a 
new route set based on the presence or absence of a Record-Route 
header field in any response to a PUBLISH request. 


The PUBLISH request MAY contain a Contact header field, but including 


one in a PUBLISH request has no meaning in the event publication 
context and will be ignored by the ESC. An EPA MAY send a PUBLISH 
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request within an existing dialog. In that case, the request is 
received in the context of any media session or sessions associated 
with that dialog. 


Note that while sending a PUBLISH request within an existing 
dialog is not prohibited, it will typically not result in the 
expected behavior. Unless the other end of the dialog is also an 
ESC, it will probably reject the request. 


EPAs MUST NOT send a new PUBLISH request (not a re-transmission) for 
the same Request-URI, until they have received a final response from 
the ESC for the previous one or the previous PUBLISH request has 
timed out. 


4.1. Identification of Published Event State 


Identification of published event state is provided by three pieces 
of information: Request-URI, event type, and (optionally) an entity- 
tag. 


The Request-URI of a PUBLISH request contains enough information to 
route the request to the appropriate entity per the request routing 
procedures outlined in RFC 3261 [4]. It also contains enough 
information to identify the resource whose event state is to be 
published, but not enough information to determine the type of the 
published event state. 


For determining the type of the published event state, the EPA MUST 
include a single Event header field in PUBLISH requests. The value 
of this header field indicates the event package for which this 
request is publishing event state. 


For each successful PUBLISH request, the ESC will generate and assign 
an entity-tag and return it in the SIP-ETag header field of the 2xx 
response. 


When updating previously published event state, PUBLISH requests MUST 
contain a single SIP-If-Match header field identifying the specific 
event state that the request is refreshing, modifying or removing. 
This header field MUST contain a single entity-tag that was returned 
by the ESC in the SIP-ETag header field of the response to a previous 
publication. 


The PUBLISH request MAY contain a body, which contains event state 
that the client wishes to publish. The content format and semantics 
are dependent on the event package identified in the Event header 
field. 
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The presence of a body and the SIP-If-Match header field determine 
the specific operation that the request is performing, as described 
in Table 1. 


+----------- +------- $ ooo +--------------- + 
| Operation | Body? | SIP-If-Match? | Expires Value | 
+----------- +------- +--------------- $ ooo + 
| Initial | yes | no [158 

Refresh no | yes > 0 

Modify yes yes > 0 
| Remove | no | yes | o 
+----------- +------- +--------------- +--------------- + 


Table 1: Publication Operations 


An ‘Initial’ publication sets the initial event state for a 
particular EPA. There may, of course, already be event state 
published by other EPAs (for the same address-of-record). That state 
is unaffected by an initial publication. A 'Refresh” publication 
refreshes the lifetime of a previous publication, whereas a 'Modify' 
publication modifies the event state of a previous publication. A 
‘Remove’ publication requests immediate removal of event state. 
These operations are described in more detail in the following 
sections. 


4.2. Creating Initial Publication 


An initial publication is a PUBLISH request created by the EPA and 
sent to the ESC that establishes soft state for the event package 
indicated in the Event header field of the request, and bound to the 
address in the Request-URI of the request. 


An initial PUBLISH request MUST NOT contain a SIP-If-Match header 
field. However, if the EPA expects an appropriate, locally stored 
entity-tag to still be valid, it SHOULD first try to modify that 
event state as described in Section 4.4, instead of submitting an 
initial publication. 


An initial PUBLISH request MUST contain a body that contains the 
published event state. 


An initial PUBLISH request MAY contain a single Expires header field. 


This value indicates the suggested lifetime of the event state 
publication. 
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The ESC may lower the suggested lifetime of the publication, but it 
will never extend it. If an Expires header field is not present, the 
EPA is indicating its desire for the ESC to choose. The Expires 
header field in a 2xx response to the initial PUBLISH indicates the 
actual duration for which the publication will remain active. Unless 
refreshed before this lifetime is exceeded, the publication will 
expire. 


4.3. Refreshing Event State 


An EPA is responsible for refreshing its previously established 
publications before their expiration interval has elapsed. To 
refresh a publication, the EPA MUST create a PUBLISH request that 
includes in a SIP-If-Match header field the entity-tag of the 
publication to be refreshed. 


The SIP-If-Match header field containing an entity-tag conditions the 
PUBLISH request to refresh a specific event state established by a 
prior publication. If the entity-tag matches previously published 
event state at the ESC, the refresh succeeds, and the EPA receives a 
2xx response. 


Like the 2xx response to an initial PUBLISH request, the 2xx response 
to a refresh PUBLISH request will contain a SIP-ETag header field 
with an entity-tag. The EPA MUST store this entity-tag, replacing 
any existing entity-tag for the refreshed event state. See Section 
8.2 for more information on the EPA handling of entity-tags. 


If there is no matching event state, e.g., the event state to be 
refreshed has already expired, the EPA receives a 412 (Conditional 
Request Failed) response to the PUBLISH request. 


A publication refresh MAY contain a single Expires header field. 
This value indicates the suggested lifetime of the event state. 


The ESC may lower the suggested lifetime of the publication refresh, 
but it will never extend it. If an Expires header field is not 
present, the EPA is indicating its desire for the ESC to choose. The 
Expires header field in a 2xx response to the publication refresh 
indicates the actual duration for which the publication will remain 
active. 


A publication refresh only extends the expiration time of already 
existing event state. It does not affect that event state in any 
other way. Therefore, a PUBLISH request that refreshes event state 
MUST NOT have a body. 
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4.4. Modifying Event State 


Modifying event state closely resembles the creation of initial event 
state. However, instead of establishing completely new event state 
at the ESC, already existing event state is updated with modified 
event state. The nature of this update depends on the content of the 
body, and the semantics associated with the format of that body. 


To modify event state, the EPA MUST construct a PUBLISH request that 
includes in a SIP-If-Match header field the entity-tag of the event 
state publication to be modified. A PUBLISH request that modifies 
event state MUST contain a body that includes the modified event 
state. 


The SIP-If-Match header field conditions the PUBLISH request to 
modify a specific event state established by a prior publication, and 
identified by the entity-tag. If the entity-tag matches previously 
published event state at the ESC, that event state is replaced by the 
event state carried in the PUBLISH request, and the EPA receives a 
2xx response. 


Like the 2xx response to an initial PUBLISH request, the 2xx response 
to a modifying PUBLISH request will contain a SIP-ETag header field 
with an entity-tag. The EPA MUST store this entity-tag, replacing 
any existing entity-tag for the modified event state. See Section 
8.2 for more information on the EPA handling of entity-tags. 


If there is no matching event state at the ESC, e.g., the event state 
to be modified has already expired, the EPA receives a 412 
(Conditional Request Failed) response to the PUBLISH request. 


A modifying PUBLISH request MAY contain a single Expires header 
field. This value indicates the suggested lifetime of the event 
state publication. 


The ESC may lower the suggested lifetime of the publication, but it 
will never extend it. If an Expires header field is not present, the 
EPA is indicating its desire for the ESC to choose. The Expires 
header field in a 2xx response to the modifying PUBLISH request 
indicates the actual duration for which the publication will remain 
active. Unless refreshed before this lifetime is exceeded, the 
publication will expire. 


4.5. Removing Event State 


Event state established by a prior publication may also be explicitly 
removed. 
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To request the immediate removal of event state, an EPA MUST create a 
PUBLISH request with an Expires value of "0", and set the SIP-If- 
Match header field to contain the entity-tag of the event state 
publication to be removed. 


Note that removing event state is effectively a publication 
refresh suggesting an infinitesimal expiration interval. 
Consequently, the refreshed event state expires immediately after 
being refreshed. 


Similar to an event state refresh, the removal of event state only 
affects the expiry of the event state. Therefore, a PUBLISH request 
that removes event state MUST NOT contain a body. 


5. Processing PUBLISH Responses 


When processing responses to PUBLISH requests, the steps in Section 
8.1.2 of RFC 3261 [4] apply. 


If an EPA receives a 412 (Conditional Request Failed) response, it 
MUST NOT reattempt the PUBLISH request. Instead, to publish event 
state, the EPA SHOULD perform an initial publication, i.e., a PUBLISH 
request without a SIP-If-Match header field, as described in Section 
4.2. The EPA MUST also discard the entity-tag that produced this 
error response. 


If an EPA receives a 423 (Interval Too Brief) response to a PUBLISH 
request, it MAY retry the publication after changing the expiration 
interval in the Expires header field to be equal to or greater than 
the expiration interval within the Min-Expires header field of the 
423 (Interval Too Brief) response. 


6. Processing PUBLISH Requests 


The Event State Compositor (ESC) is a User Agent Server (UAS) that 
processes and responds to PUBLISH requests, and maintains a list of 
publications for a given address-of-record. The ESC has to know 
(e.g., through configuration) the set of addresses for which it 
maintains event state. 


The ESC MUST ignore the Record-Route header field if it is included 
in a PUBLISH request. The ESC MUST NOT include a Record-Route header 
field in any response to a PUBLISH request. The ESC MUST ignore the 
Contact header field if one is present in a PUBLISH request. 
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PUBLISH requests with the same Request-URI MUST be processed in the 
order that they are received. PUBLISH requests MUST also be 
processed atomically, meaning that a particular PUBLISH request is 
either processed completely or not at all. 


When receiving a PUBLISH request, the ESC follows the steps defining 
general UAS behavior in Section 8.2 of RFC 3261 [4]. In addition, 
for PUBLISH specific behavior the ESC follows these steps: 


1. The ESC inspects the Request-URI to determine whether this request 
is targeted to a resource for which the ESC is responsible for 
maintaining event state. If not, the ESC MUST return a 404 (Not 
Found) response and skip the remaining steps. 


It may also be that the Request-URI points to a domain that the 
ESC is not responsible for. In that case, the UAS receiving the 
request can assume the role of a proxy server and forward the 
request to a more appropriate target. 


2. The ESC examines the Event header field of the PUBLISH request. 
If the Event header field is missing or contains an event package 
which the ESC does not support, the ESC MUST respond to the 
PUBLISH request with a 489 (Bad Event) response, and skip the 
remaining steps. 


3. The ESC examines the SIP-If-Match header field of the PUBLISH 
request for the presence of a request precondition. 


* If the request does not contain a SIP-If-Match header field, 
the ESC MUST generate and store a locally unique entity-tag for 
identifying the publication. This entity-tag is associated 
with the event-state carried in the body of the PUBLISH 
request. 


* Else, if the request has a SIP-If-Match header field, the ESC 
checks whether the header field contains a single entity-tag. 
If not, the request is invalid, and the ESC MUST return with a 
400 (Invalid Request) response and skip the remaining steps. 


* Else, the ESC extracts the entity-tag contained in the SIP-If- 
Match header field and matches that entity-tag against all 
locally stored entity-tags for this resource and event package. 
If no match is found, the ESC MUST reject the publication with 
a response of 412 (Conditional Request Failed), and skip the 
remaining steps. 
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4. The ESC processes the Expires header field value from the PUBLISH 
request. 


* If the request has an Expires header field, that value MUST be 
taken as the requested expiration. 


* Else, a locally-configured default value MUST be taken as the 
requested expiration. 


* The ESC MAY choose an expiration less than the requested 
expiration interval. Only if the requested expiration interval 
is greater than zero and less than a locally-configured 
minimum, the ESC MAY reject the publication with a response of 
423 (Interval Too Brief), and skip the remaining steps. This 
response MUST contain a Min-Expires header field that states 
the minimum expiration interval the ESC is willing to honor. 


5. The ESC processes the published event state contained in the body 
of the PUBLISH request. If the content type of the request does 
not match the event package, or is not understood by the ESC, the 
ESC MUST reject the request with an appropriate response, such as 
415 (Unsupported Media Type), and skip the remainder of the steps. 


* The ESC stores the event state delivered in the body of the 
PUBLISH request and identified by the associated entity-tag, 
updating any existing event state for that entity-tag. The 
expiration value is set to the chosen expiration interval. 


* If the request has no message body and contained no entity-tag, 
the ESC SHOULD reject the request with an appropriate response, 
such as 400 (Invalid Request), and skip the remainder of the 
steps. Alternatively, in case either ESC local policy or the 
event package has defined semantics for an initial publication 
containing no message body, the ESC MAY accept it. 


* Else, the event state identified by the entity-tag is 
refreshed, setting the expiration value to the chosen 
expiration interval. 


* If the chosen expiration interval has a special value of "0", 
the event state identified by the entity-tag MUST be 
immediately removed. The ESC MUST NOT store any event state as 
a result of such a request. 
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The processing of the PUBLISH request MUST be atomic. If internal 
errors (such as the inability to access a back-end database) occur 
before processing is complete, the publication MUST NOT succeed, 
and the ESC MUST fail with an appropriate error response, such as 
504 (Server Time-out), and skip the last step. 


6. The ESC returns a 200 (OK) response. The response MUST contain an 
Expires header field indicating the expiration interval chosen by 
the ESC. The response MUST also contain a SIP-ETag header field 
that contains a single entity-tag identifying the publication. 

The ESC MUST generate a new entity-tag for each successful 
publication, replacing any previous entity-tag associated with 
that event state. The generated entity-tag MUST be unique from any 
other entity-tags currently assigned to event state associated 
with that Request-URI, and MUST be different from any entity-tag 


assigned previously to event state for that Request-URI. See 
Section 8.3 for more information on the ESC handling of entity- 
tags. 


7. Processing OPTIONS Requests 


A client may probe the ESC for the support of PUBLISH using the 
OPTIONS request defined in SIP [4]. The ESC processes OPTIONS 
requests as defined in Section 11.2 of RFC 3261 [4]. In the response 
to an OPTIONS request, the ESC SHOULD include "PUBLISH" to the list 
of allowed methods in the Allow header field. Also, it SHOULD list 
the supported event packages in an Allow-Events header field. 


The Allow header field may also be used to specifically announce 
support for PUBLISH messages when registering. (See SIP Capabilities 
[12] for details). 


8. Use of Entity-tags in PUBLISH 


This section makes a general overview of the entity-tags usage in 
PUBLISH. It is informative in nature and thus contains no normative 
protocol description. 


8.1. General Notes 


The PUBLISH mechanism makes use of entity-tags, as defined in HTTP/ 
1.1 [13]. While the main functionality is preserved, the syntax and 
semantics for entity-tags and the corresponding header fields is 
adapted specifically for use with the PUBLISH method. The main 
differences are: 


o The syntax for entity-tags is a token instead of quoted-string. 
There is also no prefix defined for indicating a weak entity-tag. 
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o A PUBLISH precondition can only apply to a single entity-tag, so 
request preconditions with multiple entity-tags are not allowed. 


o A request precondition can’t apply to "any" entity, namely there 
is no special "*" entity-tag value defined for PUBLISH. 


o Whereas in HTTP/1.1 returning an entity-tag is optional for origin 
servers, in PUBLISH ESCs are required to always return an entity- 
tag for a successful publication. 


The main motivation for the above adaptation is that PUBLISH is 
conceptually an HTTP PUT, for which only a subset of the features in 
cache validation using entity-tags is allowed in HTTP/1.1. It makes 
little sense to enable features other than this subset for event 
state publication. 


To make it apparent that the entity-tags usage in PUBLISH is similar 
but not identical to HTTP/1.1, we have not adopted the header field 
names directly from HTTP/1.1, but rather have created similar but 
distinct names, as can be seen in Section 11. 


8.2. Client Usage 


Each successful publication will get assigned an entity-tag which is 
then delivered to the EPA in the response to the PUBLISH request. 
The EPA needs to store that entity-tag, replacing any previous 
entity-tag for that event state. If a request fails with a 412 
(Conditional Request Failed) response, the EPA discards the entity- 
tag that caused the failure. 


Entity-tags are opaque tokens to the EPA. The EPA cannot infer any 
further semantics from an entity-tag beyond a simple identifier, or 
assume a specific formatting. An entity-tag may be a monotonically 


increasing counter, but it may also be a totally random token. It is 
up to the ESC implementation as to what the formatting of an entity- 
tag is. 

8.3. Server Usage 


Entity-tags are generated and maintained by the ESC. They are part 
of the state maintained by the ESC that also includes the actual 
event state and its remaining expiration interval. An entity-tag is 
generated and stored for each successful event state publication, and 
returned to the EPA in a 200 (OK) response. Each event state 
publication from the EPA that updates a previous publication will 
include an entity-tag that the ESC can use as a search key in the set 
of active publications. 
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The way in which an entity-tag is generated is an implementation 
decision. One possible way to generate an entity-tag is to implement 
it as an integer counter that is incremented by one for each 
successfully processed publication. Other, equally valid ways for 
generating entity-tags exist, and this document makes no 
recommendations or preference for a single way. 


9. Controlling the Rate of Publication 


As an entity responsible for aggregating state information from 
potentially many sources, the ESC can be subject to considerable 
amounts of publication traffic. There are ways to reduce the amount 
of PUBLISH requests that the ESC receives: 


o Choice of the expiration interval for a publication can be 
affected by the ESC. It can insist that an EPA chooses a longer 
expiration value to what it suggests, in case the ESC's local 
default minimum expiration value is not reached. Maintaining a 
longer default minimum expiration value at the ESC reduces the 
rate at which publications are refreshed. 


o Another way of reducing publication traffic is to use a SIP-level 
push-back to quench a specific source of publication traffic. To 
push back on publications from a particular source, the ESC MAY 
respond to a PUBLISH request with a 503 (Service Unavailable), as 
defined in RFC 3261 [4]. This response SHOULD contain a Retry- 
After header field indicating the time interval that the 
publication source is required to wait until sending another 
PUBLISH request. 


At the time of writing this specification, work on managing load in 
SIP is starting, which may be able to provide further tools for 
managing load in event state publication systems. 


10. Considerations for Event Packages using PUBLISH 


This section discusses several issues which should be taken into 
consideration when applying the PUBLISH mechanism to event packages. 
It also demonstrates how these issues are handled when using PUBLISH 
for presence publication. 


Any future event package specification SHOULD include a discussion of 
its considerations for using PUBLISH. At a minimum those 
considerations SHOULD address the issues presented in this chapter, 
and MAY include additional considerations. 


Niemi Standards Track [Page 15] 


RFC 3903 SIP Event State Publication October 2004 


10. 


10 


10. 


1. PUBLISH Bodies 


The body of the PUBLISH request typically carries the published event 
state. Any application of the PUBLISH mechanism for a given event 
package MUST define what content type or types are expected in 
PUBLISH requests. Each event package MUST also describe the 
semantics associated with that content type, and MUST prescribe a 
default, mandatory to implement MIME type. 


This document defines the semantics of the presence publication 
requests (event package "presence") when the Common Profile for 
Presence (CPP) Presence Information Data Format (PIDF) [6] is used. 
A PUA that uses PUBLISH to publish presence state to the PA MUST 
support the PIDF presence format. It MAY support other formats. 


.2. PUBLISH Response Bodies 


The response to a PUBLISH request indicates whether the request was 
successful or not. In general, the body of such a response will be 
empty unless the event package defines explicit meaning for such a 
body. 


There is no such meaning for the body of a response to a presence 
publication. 


3. Multiple Sources for Event State 


For some event packages, the underlying model is that of a single 
entity responsible for aggregating event state (ESC), and multiple 
sources, out of which only some may be using the PUBLISH mechanism. 


Note that sources for event state other than those using the 
PUBLISH mechanism are explicitly allowed. However, it is beyond 
the scope of this document to define such interfaces. 


Event packages that make use of the PUBLISH mechanism SHOULD describe 
whether this model for event state publication is applicable, and MAY 
describe specific mechanisms used for aggregating publications from 
multiple sources. 


For presence, a PUA can publish presence state for just a subset of 
the tuples that may be composited into the presence document that 
watchers receive in a NOTIFY. The mechanism by which the ESC 
aggregates this information is a matter of local policy and out of 
the scope of this specification. 
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4. Event State Segmentation 


For some event packages, there exists a natural decomposition of 
event state into segments. Each segment is defined as one of 
potentially many identifiable sections in the published event state. 
Any event package whose content type supports such segmentation of 
event state, SHOULD describe the way in which these event state 
segments are identified by the ESC. 


In presence publication, the EPA MUST keep the "id" attributes of 
tuples consistent in the context of an entity-tag. If a publication 
modifies the contents of a tuple, that tuple MUST maintain its 
original "id". The ESC will interpret each tuple in the context of 
the entity-tag with which the request arrived. A tuple whose "id" is 
missing compared to the original publication will be considered as 
being removed. Similarly, a tuple is interpreted as being added if 
its "id" attribute is one that the original publication did not 
contain. 


5. Rate of Publication 


Controlling the rate of publication is discussed in Section 9. 
Individual event packages MAY in turn define recommendations (SHOULD 
or MUST strength) on absolute maximum rates at which publications are 
allowed to be generated by a single EPA. 


There are no rate limiting recommendations for presence publication. 
Protocol Element Definitions 


This section describes the extensions required for event publication 
in SIP. 


1. New Methods 
Lei Dee PUBLISH Method 


"PUBLISH" is added to the definition of the element "Method" in the 
SIP message grammar. As with all other SIP methods, the method name 
is case sensitive. PUBLISH is used to publish event state to an 
entity responsible for compositing this event state. 


Table 2 and Table 3 extend Tables 2 and 3 of RFC 3261 [4] by adding 
an additional column, defining the header fields that can be used in 
PUBLISH requests and responses. The keys in these tables are 
specified in Section 20 of RFC 3261 [4]. 
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Header Field 


Accept 


Accept-Encoding 
Accept-Encoding 
Accept-Encoding 
Accept-Language 
Accept-Language 
Accept-Language 


Alert-Info 
Allow 

Allow 

Allow 
Allow-Events 
Allow-Events 


Authentication-Info 
Authorization 


Call-ID 
Call-Info 
Contact 
Contact 
Contact 
Contact 
Contact 


Content-Disposition 
Content-Encoding 
Content-Language 
Content-Length 


Content-Type 
CSeq 

Date 

Event 
Error-Info 
Expires 
Expires 

From 
In-Reply-To 
Max-Forwards 
Min-Expires 
MIME-Version 
Organization 
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+ 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 

+ 


--------- + 
PUBLISH | 


1030030300 


*XTOOOOO 


e 


R 
300-699 


2XX 


JaA 


003313300303 


+ 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
e o| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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a oa 2522222 FE=+====2=e + 
Header Field | where | PUBLISH | 
Hs pa apa ss ese eS SS SSH Stee Fes + 
Priority | R | o) | 
Proxy-Authenticate | 407 | m 
Proxy-Authenticate | 401 | o 
Proxy-Authorization | R | o) 
Proxy-Require | R | O | 
Record-Route | | = | 
Reply-To = 
Require | | o | 
Retry-After | 404,413,480,486 | o 
Retry-After | 500,503 | o | 
Retry-After | 600, 603 | o | 
Route | R | € | 
Server | r | o | 
Subject R O 
Supported | R | e) | 
Supported | 2xx | o | 
Timestamp | | o | 
To | c(1) | m 
Unsupported | 420 | O | 
User-Agent o 
Via | R | m 
Via | rc | m | 
Warning | r | O | 
WWW-Authenticate | 401 | m 
WWW-Authenticate | 407 | o | 
4+—--------------------- +—---------------- Ho + 
Table 3: Summary of header fields, P--Z 
New Response Codes 
1. "412 Conditional Request Failed" Response Code 
e 412 (Conditional Request Failed) response is added to the 
lient-Error" header field definition. 412 


"E 
Fa 


iled) 


request has failed. 


Niemi 
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(Conditional Request 
is used to indicate that the precondition given for the 
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11.3. New Header Fields 


Table 4, Table 5, and Table 6 expand on Table 3 in SIP [4], as 
amended by the changes in Section 11.1. 


4+-------------- 4+------- 4+------- 4+----- +----- 4+----- 4+----- 4+----- + 
| Header Field | where | proxy | ACK | BYE | CAN | INF | INV | 
4+-------------- 4+------- 4+------- +----- +----- 4+----- +----- 4+----- + 

SIP-ETag 2XX = = 7 z 7 
SIP-If-Match R - - - - - 
Ho 4+------- 4+------- 4+----- 4+----- 4+----- +----- 4+----- + 
Table 4: Summary of header fields, P--Z 
4+-------------- 4+------- 4+------- 4+----- 4+----- 4+----- +----- 4+----- + 
| Header Field | where | proxy | NoT | OPT | PRA | REG | SUB | 
4+-------------- 4+------- 4+------- 4+----- 4+----- 4+----- +----- 4+----- + 
| SIP-ETag | 2xx | a E a See 
| SIP-If-Match | R | L- | = | - | - | - | 
4+-------------- 4+------- 4+------- +----- 4+----- 4+----- 4+----- 4+----- + 
Table 5: Summary of header fields, P--Z 
Ho 4+------- +------- 4+----- 4+----- 4+----- 4+--------- + 
| Header Field | where | proxy | UPD | MSG | REF | PUBLISH | 
4+-------------- 4+------- 4+------- 4+----- +----- 4+----- 4+--------- + 

| SIP-ETag | 2XX | | = | = | = | m 
| SIP-If-Match | R | | - | - | - | o 
4+-------------- 4+------- 4+------- 4+----- 4+----- +----- 4+--------- + 
Table 6: Summary of header fields, P--Z 
11.3.1. "SIP-ETag" Header Field 


SIP-ETag is added to the definition of the element "general-header" 
in the SIP message grammar. Usage of this header is described in 
Section 4 and Section 6. 


11.3.2. "SIP-If-Match" Header Field 
SIP-If-Match is added to the definition of the element "general- 


header" in the SIP message grammar. Usage of this header is 
described in Section 4 and Section 6. 
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Augmented BNF Definitions 


This section describes the syntax extensions required for event 
publication in SIP. The formal syntax definitions described in this 
section are expressed in the Augmented BNF [7] format used in SIP 
[4], and contain references to elements defined therein. 


PUBLISHm = $x50.55.42.4C.49.53.48 ; PUBLISH in caps. 
extension-method = PUBLISHm / token 

SIP-ETag = "SIP-ETag" HCOLON entity-tag 
SIP-If-Match = "SIP-If-Match" HCOLON entity-tag 
entity-tag = token 


IANA Considerations 


This document registers a new method name, a new response code and 
two new header field names. 


1. Methods 


This document registers a new SIP method, defined by the following 
information, which has been added to the method and response-code 
sub-registry under http://www.iana.org/assignments/sip-parameters. 


Method Name: PUBLISH 
Reference: [RFC3903] 
.2. Response Codes 
This document registers a new response code. This response code is 


defined by the following information, which has been added to the 
method and response-code sub-registry under 
http://www.iana.org/assignments/sip-parameters. 


Response Code Number: 412 
Default Reason Phrase: Conditional Request Failed 


3. Header Field Names 


This document registers two new SIP header field names. These 
headers are defined by the following information, which has been 
added to the header sub-registry under 
http://www.iana.org/assignments/sip-parameters. 


Header Name: SIP-ETag 
Compact Form: (none) 
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Header Name: SIP-If-Match 
Compact Form: (none) 


Security Considerations 
1. Access Control 


Since event state may be considered sensitive information, the ESC 
should have the ability to selectively accept publications from 
authorized sources only, based on the identity of the EPA. 


The state agent SHOULD authenticate the EPA, and SHOULD apply its 
authorization policies (e.g., based on access control lists) to all 
requests. The composition model makes no assumptions that all input 
sources for an ESC are on the same network, or in the same 
administrative domain. 


ESCs and EPAs MUST implement Digest for authenticating PUBLISH 
requests, as defined in RFC 3261 [4]. The exact methods for creating 
and manipulating access control policies in the ESC are outside the 
scope of this document. 


-2. Denial of Service Attacks 


The creation of state at the ESC upon receipt of a PUBLISH request 
can be used by attackers to consume resources on a victim’s machine, 
possibly rendering it unusable. 


To reduce the chances of such an attack, implementations of ESCs 
SHOULD require authentication of PUBLISH requests. Implementations 
MUST support Digest authentication, as defined in RFC 3261 [4]. 


Also, the ESC SHOULD throttle incoming publications and the 
corresponding notifications resulting from the changes in event 
state. As a first step, careful selection of default minimum Expires 
header field values for the supported event packages at an ESC can 
help limit refreshes of event state. 


Additional throttling and debounce logic at the ESC is advisable to 
further reduce the notification traffic produced as a result of a 
PUBLISH request. 


3. Replay Attacks 


Replaying a PUBLISH request can have detrimental effects. An 
attacker may be able to perform any event state publication it 
witnessed being performed at some point in the past, by replaying 
that PUBLISH request. Among other things, such a replay message may 
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be used to spoof old event state information, although a versioning 
mechanism, e.g., a timestamp, in the state information may help 
mitigate such an attack. 


To prevent replay attacks, implementations MUST support Digest 
authentication with replay protection, as defined in RFC 3261 [4]. 
Further mechanisms for countering replay attacks are discussed in SIP 
[4]. 


14.4. Man in the Middle Attacks 


Even with authentication, man-in-the-middle attacks using PUBLISH may 
be used to install arbitrary event state information, modify or 
remove existing event state information in publications, or even 
remove event state altogether at an ESC. 


To prevent such attacks, implementations SHOULD, at a minimum, 
provide integrity protection across the To, From, Event, SIP-If- 
Match, Route, and Expires header fields and the bodies of PUBLISH 
requests. 


If the ESC receives event state in a PUBLISH request which is 
integrity protected using a security association that is not with the 
ESC (e.g., integrity protection is applied end-to-end, from publisher 
to subscriber), the state agent coupled with the ESC MUST NOT modify 
the event state before exposing it to the subscribers of this event 
state in NOTIFY requests. This is to preserve the end-to-end 
integrity of the event state. 


For integrity protection, ESCs MUST implement TLS [8], and MUST 
support both mutual and one-way authentication, and MUST also support 
the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of 
initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs 
MAY support S/MIME [9] for integrity protection, as defined in SIP 
[4]. 


14.5. Confidentiality 


The state information contained in a PUBLISH message may potentially 
contain sensitive information. Implementations MAY encrypt such 
information to ensure confidentiality. 


For providing confidentiality, ESCs MUST implement TLS [8], MUST 
support both mutual and one-way authentication, and MUST also support 
the SIPS URI scheme defined in SIP [4]. EPAs SHOULD be capable of 
initiating TLS and SHOULD support the SIPS URI scheme. ESCs and EPAs 
MAY support S/MIME [9] for encryption of event state information, as 
defined in SIP [4]. 
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This section shows an example of using the PUBLISH method for 
publishing a presence document from a presence user agent to a 


presence agent. 
presentity's presence information from the PA. 
SUBSCRIBE to its own presence to see the composite presence 


exposed by the PA. 
and is not shown in this example. 


This is an optional but likely step for 


When the value of the Content-Length header field is "... 
that the value should be whatever the computed length of the body is. 


Niemi 


PUA 
(EPA 


) 

---- M5: 
<--- M6: 
---- M9: 
<--- M10: 
--- Mill: 
<-- M12: 


PA 
(ESC) 
<a S55) Mis 
| 
| ----- M2: 
| 
| ----- M3: 
| 
| 
PUBLISH ---> | 
| 
200 OK ---- | 
| Sonne M7: 
| 
| <---- M8 
| 
PUBLISH ---> | 
200 OK --- | 
| 
| 
PUBLISH ---> | 
200 OK ---- | 
| 
| ----- M13: 
| 
| <---- M14: 
| 
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SUBSCRI 


NOTIFY 


200 OK 


The watcher in this example is subscribing 
The PUA may 


to the 
also 
state 
the PUA, 


this means 


WATCHER 


BE --- 


----> 
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Message flow: 


M1: The watcher initiates a new subscription to the 
presentity@example.com’s presence agent. 


SUBSCRIBE sip:presentity@example.com SIP/2.0 
Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7 
To: <sip:presentity@example.com> 

From: <sip:watcher@example.com>; tag=12341234 
Call-ID: 12345678@host.example.com 

CSeq: 1 SUBSCRIBE 

Max-Forwards: 70 

Expires: 3600 

Event: presence 

Contact: sip:user@host.example.com 
Content-Length: 0 


M2: The presence agent for presentity@example.com processes the 
subscription request and creates a new subscription. A 200 (OK) 
response is sent to confirm the subscription. 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP host.example.com;branch=z9hG4bKnashds7 
; received=192.0.2.1 

To: <sip:presentity@example.com>; tag=abcd1234 

From: <sip:watcher@example.com>; tag=12341234 

Call-ID: 12345678@host.example.com 

CSeq: 1 SUBSCRIBE 

Contact: sip:pa.example.com 

Expires: 3600 

Content-Length: 0 


M3: In order to complete the process, the presence agent sends the 
watcher a NOTIFY with the current presence state of the 
presentity. 


NOTIFY sip:user@host.example.com SIP/2.0 

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 
To: <sip:watcher@example.com>;tag=12341234 
From: <sip:presentity@example.com>;tag=abcd1234 
Call-ID: 12345678@host.example.com 

CSeq: 1 NOTIFY 

Max-Forwards: 70 

Event: presence 

Subscription-State: active; expires=3599 
Contact: sip:pa.example.com 

Content-Type: application/pidf+xml 
Content-Length: 
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[PIDF document] 
The watcher confirms receipt of the NOTIFY request. 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK8sdf2 
; received=192.0.2.2 

To: <sip:watcher@example.com>;tag=12341234 

From: <sip:presentity@example.com>;tag=abcd1234 

Call-ID: 12345678@host.example.com 

CSeq: 1 NOTIFY 


A presence user agent (acting for the presentity) initiates a 
PUBLISH request to the presence agent in order to update it with 
new presence information. The Expires header field indicates the 
suggested duration for this event soft state. 


PUBLISH sip:presentity@example.com SIP/2.0 

Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge 
To: <sip:presentity@example.com> 

From: <sip:presentity@example.com>;tag=1234wxyz 
Call-ID: 81818181@pua.example.com 

CSeq: 1 PUBLISH 

Max-Forwards: 70 

Expires: 3600 

Event: presence 

Content-Type: application/pidf+xml 
Content-Length: 


[Published PIDF document ] 


The presence agent receives, and accepts the presence 
publication. The published data is incorporated into the 
presentity’s presence information. 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP pua.example.com; branch=z9hG4bK652hsge 
; received=192.0.2.3 

To: <sip:presentity@example.com>;tag=la2b3c4d 

From: <sip:presentity@example.com>;tag=1234wxyz 

Call-ID: 81818181@pua.example.com 

CSeq: 1 PUBLISH 

SIP-ETag: dx200xyz 

Expires: 1800 


The presence agent determines that a reportable change has been 


made to the presentity’s presence information, and sends a 
new presence notification to the watcher. 
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NOTIFY sip:user@host.example.com SIP/2.0 

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a 
To: <sip:watcher@example.com>;tag=12341234 
From: <sip:presentity@example.com>;tag=abcd1234 
Call-ID: 12345678@host.example.com 

CSeq: 2 NOTIFY 

Max-Forwards: 70 

Event: presence 

Subscription-State: active; expires=3400 
Contact: sip:pa.example.com 

Content-Type: application/pidf+xml 
Content-Length: 


[New PIDF document ] 
The watcher confirms receipt of the NOTIFY request. 


sIP/2.0 200 OK 

Via: SIP/2.0/UDP pa.example.com;branch=z9hG4bK4cd42a 
; received=192.0.2.2 

To: <sip:watcher@example.com>;tag=12341234 

From: <sip:presentity@example.com>;tag=abcd1234 

Call-ID: 12345678@host.example.com 

CSeq: 2 NOTIFY 

Content-Length: 0 


The PUA determines that the event state it previously published 
is about to expire, and refreshes that event state. 


PUBLISH sip:presentity@example.com SIP/2.0 

Via: SIP/2.0/UDP pua.example.com; branch=z9hG4bK771lash02 
To: <sip:presentity@example.com> 

From: <sip:presentity@example.com>;tag=1234k1jk 
Call-ID: 98798798@pua.example.com 

CSeq: 1 PUBLISH 

Max-Forwards: 70 

SIP-If-Match: dx200xyz 

Expires: 3600 

Event: presence 

Content-Length: 0 


The presence agent receives, and accepts the publication 
refresh. The timers regarding the expiration of the specific 
event state identified by the entity-tag are updated. As always, 
the ESC returns an entity-tag in the response to a successful 
PUBLISH. Note that no actual state change has occurred, so the 
watchers will receive no NOTIFYs. 
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sIP/2.0 200 OK 

Via: SIP/2.0/UDP pua.example.com;¡branch=z9hG4bK771ash02 
; received=192.0.2.3 

To: <sip:presentity@example.com>;tag=2Zaffde434 

From: <sip:presentity@example.com>;tag=1234k1jk 

Call-ID: 98798798@pua.example.com 

CSeq: 1 PUBLISH 

SIP-ETag: kw j449x 

Expires: 1800 


M11: The PUA of the presentity detects a change in the user's 


presence state. It initiates a PUBLISH request to the presence 
agent to modify the published presence information with the recent 
change. 


PUBLISH sip:presentity@example.com SIP/2.0 
Via: SIP/2.0/UDP pua.example.com; branch=z9hG4bKcdad2 
To: <sip:presentity@example.com> 

From: <sip:presentity@example.com>;tag=54321mm 
Call-ID: 5566778@pua.example.com 

CSeq: 1 PUBLISH 

Max-Forwards: 70 

SIP-If-Match: kw j449x 

Expires: 3600 

Event: presence 

Content-Type: application/pidf+xml 
Content-Length: 


[Published PIDF Document] 


M12: The presence agent receives, and accepts the modifying 
publication. The published data is incorporated into the 
presentity's presence information, updating the previous 
publication from the same PUA. 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP pua.example.com; branch=z9hG4bKcdad2 
; received=192.0.2.3 

To: <sip:presentity@example.com>;tag=effe22aa 

From: <sip:presentity@example.com>;tag=54321mm 

Call-ID: 5566778@pua.example.com 

CSeq: 1 PUBLISH 

SIP-ETag: qwi982ks 

Expires: 3600 


M13: The presence agent determines that a reportable change has been 


made to the presentity’s presence document, and sends a 
new presence notification to all active subscriptions. 
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NOTIFY sip:user@host.example.com SIP/2.0 

Via: SIP/2.0/UDP pa.example.com; branch=z9hG4bK32defd3 
To: <sip:watcher@example.com>;tag=12341234 
From: <sip:presentity@example.com>;tag=abcd1234 
Call-ID: 12345678@host.example.com 

CSeq: 2 NOTIFY 

Max-Forwards: 70 

Event: presence 

Subscription-State: active; expires=3400 
Contact: sip:pa.example.com 

Content-Type: application/pidf+xml 
Content-Length: 


[New PIDF document] 
4: The watcher confirms receipt of the NOTIFY request. 


SIP/2.0 200 OK 

Via: SIP/2.0/UDP pa.example.com; branch=z9hG4bK32defd3 
; received=192.0.2.3 

To: <sip:watcher@example.com>;tag=12341234 

From: <sip:presentity@example.com>;tag=abcd1234 

Call-ID: 12345678@host.example.com 

CSeq: 2 NOTIFY 

Content-Length: 0 
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